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Chargeable User Identity 
Status of This Memo 


This document specifies an Internet standards track protocol for the 
Internet community, and requests discussion and suggestions for 


improvements. Please refer to the current edition of the "Internet 
Official Protocol Standards" (STD 1) for the standardization state 
and status of this protocol. Distribution of this memo is unlimited. 


Copyright Notice 
Copyright (C) The Internet Society (2006). 

Abstract 
This document describes a new Remote Authentication Dial-In User 
Service (RADIUS) attribute, Chargeable-User-Identity. This attribute 
can be used by a home network to identify a user for the purpose of 


roaming transactions that occur outside of the home network. 
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1. Introduction 


Some authentication methods, including EAP-PEAP, EAP-TTLS, EAP-SIM 
and EAP-AKA, can hide the true identity of the user from RADIUS 
servers outside of the user’s home network. In these methods, the 
User-Name(1) attribute contains an anonymous identity (e.g., 
@example.com) sufficient to route the RADIUS packets to the home 
network but otherwise insufficient to identify the user. While this 
mechanism is good practice in some circumstances, there are problems 
if local and intermediate networks require a surrogate identity to 
bind the current session. 


This document introduces an attribute that serves as an alias or 
handle (hereafter, it is called Chargeable-User-Identity) to the real 
user’s identity. Chargeable-User-Identity can be used outside the 
home network in scenarios that traditionally relied on User-Name (1) 
to correlate a session to a user. 


For example, local or intermediate networks may limit the number of 
simultaneous sessions for specific users; they may require a 
Chargeable-User-Identity in order to demonstrate willingness to pay 
or otherwise limit the potential for fraud. 


This implies that a unique identity provided by the home network 
should be able to be conveyed to all parties involved in the roaming 
transaction for correlating the authentication and accounting 
packets. 


Providing a unique identity, Chargeable-User-Identity (CUI), to 
intermediaries, is necessary to fulfill certain business needs. This 
should not undermine the anonymity of the user. The mechanism 
provided by this document allows the home operator to meet these 
business requirements by providing a temporary identity representing 
the user and at the same time protecting the anonymity of the user. 


When the home network assigns a value to the CUI, it asserts that 
this value represents a user in the home network. The assertion 


should be temporary -- long enough to be useful for the external 
applications and not too long such that it can be used to identify 
the user. 


Several organizations, including WISPr, GSMA, 3GPP, Wi-Fi Alliance, 
and IRAP, have been studying mechanisms to provide roaming services, 
using RADIUS. Missing elements include mechanisms for billing and 
fraud prevention. 
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The CUI attribute is intended to close operational loopholes in 
RADIUS specifications that have impacted roaming solutions 
negatively. Use of the CUI is geared toward EAP methods supporting 
privacy (such as PEAP and EAP-TTLS), which are, for the most part, 
recent deployments. A chargeable identity reflecting the user 
profile by the home network is needed in such roaming scenarios. 


1.1. Motivation 


Some other mechanisms have been proposed in place of the CUI 


attribute. These mechanisms are insufficient or cause other 
problems. It has been suggested that standard RADIUS Class(25) or 
User-Name (1) attributes could be used to indicate the CUI. However, 


in a complex global roaming environment where there could be one or 
more intermediaries between the NAS [RFC4282] and the home RADIUS 
server, the use of aforementioned attributes could lead to problems 
as described below. 


- On the use of RADIUS Class(25) attribute: 


[RFC2865] states: "This Attribute is available to be sent by the 
server to the client in an Access-Accept packet and SHOULD be sent 
unmodified by the client to the accounting server as part of the 
Accounting-Request packet if accounting is supported. The client 
MUST NOT interpret the attribute locally." So RADIUS clients or 
intermediaries MUST NOT interpret the Class(25) attribute, which 
precludes determining whether it contains a CUI. Additionally, 
there could be multiple class attributes in a RADIUS packet, and 
since the contents of Class(25) attribute is not to be interpreted 
by clients, this makes it hard for the entities outside the home 
network to determine which one contains the CUI. 


— On the use of RADIUS User-Name(1) attribute: 


The User-Name(1) attribute included in the Access-—Request packet 
may be used for the purpose of routing the Access-Request packet, 
and in the process may be rewritten by intermediaries. Asa 
result, a RADIUS server receiving an Access-—Request packet relayed 
by a proxy cannot assume that the User-Name(1) attribute remained 
unmodified. 


On the other hand, rewriting of a User-Name(1) attribute sent 
within an Access-Accept packet occurs more rarely, since a 
Proxy-State(33) attribute can be used to route the Access-Accept 
packet without parsing the User-Name(1) attribute. As a result, a 
RADIUS server cannot assume that a proxy stripping routing 
information from a User-Name(1) attribute within an Access—Request 
packet will add this information to a User-Name(1) attribute 
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included within an Access-Accept packet. The result is that when 
a User-Name(1) attribute is sent in an Access-Accept packet, it is 
possible that the Access-—Request packet and Accounting-—Request 
packets will follow different paths. Where this outcome is 
undesirable, the RADIUS client should use the original 
User-Name(1) in accounting packets. Therefore, another mechanism 
is required to convey a CUI within an Access-Accept packet to the 
RADIUS client, so that the CUI can be included in the accounting 
packets. 


The CUI attribute provides a solution to the above problems and 
avoids overloading RADIUS User-Name(1) attribute or changing the 
usage of existing RADIUS Class(25) attribute. The CUI therefore 
provides a standard approach to billing and fraud prevention when EAP 
methods supporting privacy are used. It does not solve all related 
problems, but does provide for billing and fraud prevention. 


1.2. Terminology 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
"SHOULD", “SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in [RFC2119]. 


The following acronyms are used: 


3GPP - Third Generation Partnership Project 

AAA - Authentication, Authorization, and Accounting 
AKA - Authentication and Key Agreement 

CUI - Chargeable-User-Identity 

GSMA - GSM Association 

TRAP - International Roaming Access Protocols Program 
NAS - Network Access Server 

PEAP - Protected Extensible Authentication Protocol 
SIM - Subscriber Identity Modules 

TTLS - Tunneled Transport Layer Security 

WISPr - Wireless ISP Roaming 

WPA - Wi-Fi Protected Access 
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2. Operation 


This document assumes that the RADIUS protocol operates as specified 
in [RFC2865] and [RFC2866], dynamic authorization as specified in 
[RFC3576], and the Diameter protocol as specified in [RFC3588]. 


2.1. Chargeable-User-Identity (CUI) Attribute 


The CUI attribute serves as an alias to the user’s real identity, 
representing a chargeable identity as defined and provided by the 
home network as a supplemental or alternative information to 
User-Name(1). Typically, the CUI represents the identity of the 
actual user, but it may also indicate other chargeable identities 
such as a group of users. RADIUS clients (proxy or NAS) outside the 
home network MUST NOT modify the CUI attribute. 


The RADIUS server (a RADIUS proxy, home RADIUS server) may include 
the CUI attribute in the Access-Accept packet destined to a roaming 
partner. The CUI support by RADIUS infrastructure is driven by the 
business requirements between roaming entities. Therefore, a RADIUS 
server supporting this specification may choose not to send the CUI 
in response to an Access-Request packet from a given NAS, even if the 
NAS has indicated that it supports CUI. 


If an Access-Accept packet without the CUI attribute was received by 
a RADIUS client that requested the CUI attribute, then the 
Access-Accept packet MAY be treated as an Access-—Reject. 


If the CUI was included in an Access-Accept packet, RADIUS clients 
supporting the CUI attribute MUST ensure that the CUI attribute 
appears in the RADIUS Accounting-Request (Start, Interim, and Stop). 
This requirement applies regardless of whether the RADIUS client 
requested the CUI attribute. 


RFC 2865 includes the following statements about behaviors of RADIUS 
client and server with respect to unsupported attributes: 


- "A RADIUS client MAY ignore Attributes with an unknown Type." 
- "A RADIUS server MAY ignore Attributes with an unknown Type." 


Therefore, RADIUS clients or servers that do not support the CUI may 
ignore the attribute. 


A RADIUS client requesting the CUI attribute in an Access-—Accept 
packet MUST include within the Access-—Request packet a CUI attribute. 
For the initial authentication, the CUI attribute will include a 
single NUL character (referred to as a nul CUI). And, during 
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re-authentication, the CUI attribute will include a previously 
received CUI value (referred to as a non-null CUI value) in the 
Access-—Accept. 


Upon receiving a non-nul CUI value in an Access-—Request, the home 
RADIUS server MAY verify that the value of CUI matches the CUI from 
the previous Access-Accept. If the verification fails, then the 
RADIUS server SHOULD respond with an Access-Reject message. 


If a home RADIUS server that supports the CUI attribute receives an 
Access-Request packet containing a CUI (set to nul or otherwise), it 
MUST include the CUI attribute in the Access-Accept packet. 
Otherwise, if the Access-Request packet does not contain a CUI, the 
home RADIUS server SHOULD NOT include the CUI attribute in the 
Access-Accept packet. The Access-Request may be sent either in the 
initial authentication or during re-authentication. 


A NAS that requested the CUI during re-authentication by including 
the CUI in the Access-—Request will receive the CUI in the 
Access-Accept. The NAS MUST include the value of that CUI in all 
Accounting Messages. 


2.2. CUI Attribute 


A summary of the RADIUS CUI attribute is given below. 


012345678901234567890123456789021 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Type | Length | String 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


Type: 89 for Chargeable-User-Identity. 
Length: >= 3 
String: 


The string identifies the CUI of the end-user. This string value 
is a reference to a particular user. The format and content of 
the string value are determined by the Home RADIUS server. The 
binding lifetime of the reference to the user is determined based 
on business agreements. For example, the lifetime can be set to 
one billing period. RADIUS entities other than the Home RADIUS 
server MUST treat the CUI content as an opaque token, and SHOULD 
NOT perform operations on its content other than a binary equality 
comparison test, between two instances of CUI. In cases where the 
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3: 


attribute is used to indicate the NAS support for the CUI, the 
string value contains a nul character. 


Attribute Table 


The following table provides a guide to which attribute(s) may be 
found in which kinds of packets, and in what quantity. 


Request Accept Reject Challenge Accounting # Attribute 
Request 
0-1 0-1 0 0 0-1 89 Chargeable-User-Identity 


Note: If the Access-Accept packet contains CUI, then the NAS MUST 
include the CUI in Accounting Requests (Start, Interim, and Stop) 
packets. 


Diameter Consideration 


Diameter needs to define an identical attribute with the same Type 
value. The CUI should be available as part of the NASREQ application 
[RFC4005]. 


IANA Considerations 


This document uses the RADIUS [RFC2865] namespace; see 
http://www.iana.org/assignments/radius-types. The IANA has assigned 
a new RADIUS attribute number for the CUI attribute. 


CUI 89 
Security Considerations 


It is strongly recommended that the CUI format used is such that the 
real user identity is not revealed. Furthermore, where a reference 
is used to a real user identity, it is recommended that the binding 
lifetime of that reference to the real user be kept as short as 
possible. 


The RADIUS entities (RADIUS proxies and clients) outside the home 
network MUST NOT modify the CUI or insert a CUI in an Access-Accept. 
However, there is no way to detect or prevent this. 


Attempting theft of service, a man-in-the-middle may try to insert, 
modify, or remove the CUI in the Access-Accept packets and Accounting 
packets. However, RADIUS Access-Accept and Accounting packets 
already provide integrity protection. 
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8. 


8. 


8 


If the NAS includes CUI in an Access-Request packet, a 
man-in-the-middle may remove it. This will cause the Access-Accept 
packet to not include a CUI attribute, which may cause the NAS to 
reject the session. To prevent such a denial of service (DoS) 
attack, the NAS SHOULD include a Message-Authenticator(80) attribute 
within Access-Request packets containing a CUI attribute. 
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